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METHOD AND APPARATUS FOR PROVIDING A PROTECTED INTELLECTUAL 
PROPERTY HARDWARE 

Philippe Molson, Tony San 

5 BACKGROUND OF THE INVENTION 

Field of the Invention 

This invention relates generally to methods, machine readable media and apparatus for 
protecting intellectual property ("IP"). More specifically, this invention relates to a technique for 
. = providing controlled use of IP. 
10 

Description of Related Art 
~ ' Electronic design automation ("EDA") is becoming increasingly complicated and time 

consuming, due in part to the greatly increasing size and complexity of the electronic devices 

designed by EDA tools. Such devices include general purpose microprocessors as well as 
=15 custom logic devices including programmable logic devices. The design of even the simplest of 

these devices typically involves generation of a high level design, logic simulation, generation of 

a network, timing simulation, etc. 

A programmable logic device ("PLD") is a programmable integrated circuit that allows 

the user of the circuit, using software control, to program the PLD to perform particular logic 
20 functions. A wide variety of these devices are manufactured by Altera Corporation of San Jose, 

California. A more complete description of these types of devices and their uses can be found at 
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"www.altera.com" and in various materials published by Altera, but the basic structure and 
operation of PLDs are well known to those of ordinary skill in the art. Logic functions 
performed by small, medium, and large-scale integration integrated circuits can instead be 
performed by programmable logic devices. When an integrated circuit manufacturer supplies a 
5 typical programmable logic device, it is not yet capable of performing any specific function. The 
user, in conjunction with software supplied by the manufacturer or created by the user or an 
affiliated source, can program the PLD to perform a particular function or functions required by 
the user's application. The PLD then can function in a larger system designed by the user just as 
though dedicated logic chips were employed. 

1 0 One such improvement is the development of so-called "megafunctions" by companies 

such as Altera Corporation. A more complete description of these megafunctions and their uses 
can be found at "www.altera.com" and in various materials published by Altera. Briefly, 
megafunctions are ready made, pre-tested functional blocks that complement and augment 
existing design methodologies. When implementing complex system architectures, these 

1 5 megafunctions significantly enhance the design process. By using megafunctions, designers can 
focus more time and energy on improving and differentiating their system-level product, rather 
than re-designing common, off the shelf functions. 

Megafunctions are pre-verified design files for complex system-level functions which 
reduce the design task to creating the custom logic surrounding such commonly used system- 

20 level functions, dramatically shortening the design cycle and leveraging existing IP. Typically, 
an IP owner provides all of the files necessary to design with the megafunctions. Current 
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practice allows designers to instantiate, compile and simulate a function to verify its size and 
performance. However, programming files and output files for EDA tool simulation can be 
generated only with an authorization code provided when the megafunction is licensed. Test 
vectors and a post-synthesis design file (a fully minimized and optimized netlist that can be used 
5 without risk of changes during processing) are supplied for simulation in appropriate software 
(such as Altera' s MAX+PLUS II and QUARTUS software products) . 

A typical design cycle (using, for example, Altera' s OpenCore technology) is shown in 
Fig. 1. A designer creates an initial block diagram 110 and subsequently identifies any 
megafunctions available for use in the anticipated system 120. The designer then can identify 
10 and evaluate one or more specific megafunctions 130 in terms of functionality and the range of 
parameterization available. After finding the appropriate megafunction(s), the designer installs 
the megafunction(s) 140 and, using software, simulates performance 150 within the anticipated 
circuitry and system. 

However, software simulations of these megafunctions in complex IP frequently are 
15 limited in a number of respects. For example, many hours of software simulation of a circuit 
used in a voice over technology might translate into only a few seconds of equivalent simulated 
circuit activity on a hardware platform. As a further example, components of devices may be 
able to achieve an extremely high number of states, all of which the designer may need to test. 
However, due to the relatively slow speed of some software simulations, only a limited number 
20 of states might be testable by such software simulation. Because a hardware platform may run at 
much higher speeds than software simulations, a designer may need to test the design on a 
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hardware platform as well. With regard to PLDs, software simulation for several hours 
(representing a few seconds of PLD hardware operation) might represent appropriate sample 
testing for a design. Yet, to thoroughly validate the core of a PLD used in such an application, 
the system must run for a minute or more, thus making thorough software simulation testing 
5 impractical. Therefore, complex IP (for example, in video applications or voice over IP) should 
be evaluated and validated on a hardware platform before being purchased. In such applications, 
in order to fully validate and complete the system's design, as called for in step 160, the system 
frequently operates on a hardware prototype platform for a longer period of time than is practical 
for software simulation. A hardware prototype platform is substantially identical to the 

10 production version of the hardware a designer intends to create. The hardware prototype can be a 
PLD or other device, or a system or subsystem of the total design to be created. As will be 
appreciated by those of ordinary skill in the art, the particulars of a hardware prototype are 

: J dependent upon the needs and circumstances of the project being undertaken by a designer and 
will vary widely. In the context of this disclosure, the term "hardware prototype" will mean any 

f 5 hardware platform suitable for testing the hardware and available software for the system being 
designed. The term "production hardware" means the desired final configuration of any 
hardware that the designer intends to achieve. 

Once this prototype validation is completed, the IP used can be incorporated into specific 
devices 170 and be put into production use. This prior design process has allowed IP owners to 

20 control use of their IP up through design simulation (step 150 in Fig. 1). After software 

simulation and synthesis, the IP owner provides a temporary license file to a customer, which 
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authorizes the customer to generate a programming object file (a "POF" file) of the design 
containing the IP and to establish the hardware prototype. 

To date, IP owners have had to rely on legal contracts and/or other, unverifiable means to 
limit and control use of their IP on hardware platforms during prototype testing (step 1 50 of Fig. 
5 1) and during production use (step 170 of Fig. 1). Customers have been able to generate a POF 
file that could be used both for prototype testing as well as in production. Unauthorized use in 
production deprives the IP owner of compensation for use of its IP and inhibits the owner's 
control of its property. Attempts at technical measures to prevent unauthorized use of IP also 
have been only modestly effective. For example, there have been attempts to send an entire 
10 prototype "package" (a PLD with the system installed and with its own power supply) to a 
customer for limited testing. Such a pre-packaged system was intended to allow hardware 
testing, without unauthorized production use. However, the delicate nature of these systems and 
the need for the IP owner to incur significant costs in this method make it unattractive and 
ineffective. 

1 5 Techniques that permit more thorough development of digital systems and devices by 

designers while protecting the proprietary interests of the owners of the intellectual property 
incorporated in such systems and devices would represent a significant advancement in the art. 
Moreover, these techniques can be extended to allow an IP owner to limit or prevent 
unauthorized use of its IP in other settings and contexts. 
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BRIEF SUMMARY OF THE INVENTION 
The present invention provides to an end customer IP hardware which is suitable for 
prototype testing or controllable production operation by the IP owner. One technique limits the 
5 physical or electrical mode of operation of a hardware platform using intellectual property (such 
as limiting the number of electrical contacts between the hardware and an external electrical 
device or limiting the data format(s) usable in the hardware during prototype testing). Another 
technique limits the temporal operation of a hardware platform using an internal counter within 
the software provided by the intellectual property owner. Once a clock count limit is reached, 
10 the software disables the hardware in one or more prescribed ways, such as a reset of one or more 
registers, a global tri-state of the hardware 10, or a random failure of some type. Suitable 
hardware fabrication and/or augmentation also may be used to differentiate between the 
prototype and production manners of operation. 

The present invention provides to methods, machine readable media and apparatus for 
15 protecting intellectual property ("IP"). In one embodiment of the invention, first and second 
ranges of operation of an operational parameter are identified in which at least a portion of the 
first operation range is outside of the second operation range. Operation of the hardware is then 
limited to the portion of the first operation range outside of the second operation range. 
Operation of the hardware may be limited by the configuration of the hardware itself or by 
20 controls present in the software used in connection with the hardware. 

In another embodiment of the invention, the first operation range is a prototype operation 
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range and the second operation range is a production operation range. The hardware can then be 
controlled by the IP owner by allowing use of the hardware in a prototype operation while 
preventing production use of the hardware. Control of the hardware and/or software can be 
maintained using various means, including temporal, physical and electrical controls. In one 
embodiment, the IP owner provides a designer or other user with a POF file that permits only 
limited use of the IP, as controlled by the IP owner. 

Further details and advantages of the invention are provided in the following Detailed 
Description and the associated figures. 



-8- 



ALTRP058/A590 



BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWING 
The present invention will be readily understood by the following detailed description in 
conjunction with the accompanying drawings, wherein like reference numerals designate like 
5 structural elements, and in which: 

FIG. 1 is a block diagram showing a prior art design cycle for a digital system. 
FIG. 2A is a block diagram showing a design cycle for a digital system in which the 
design cycle incorporates one embodiment of the present invention for controlling testing of 
prototype hardware and IP. 
10 FIG. 2B is a block diagram showing a technique for controlling downloading of IP 

according to one embodiment of the present invention. 

FIG. 2C is a block diagram showing a technique for controlling prototype testing of 
hardware using a counter according to one embodiment of the present invention. 

FIG. 3 Is a block diagram showing a design cycle for a digital system in which the design 
15 cycle incorporates one embodiment of the present invention for controlling production operation 
of hardware and IP. 

Figure 4 is a block diagram of a computer system that may be used to implement various 
aspects of this invention such as the various image analysis algorithms of this invention. 
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DETAILED DESCRIPTION OF THE INVENTION 
The following detailed description of the invention will be with reference to one or more 
embodiments of the invention, but is not limited to such embodiments. The detailed description 
is intended only to be illustrative. Those skilled in the art will readily appreciate that the detailed 
description given herein with respect to the FIGURES is provided for explanatory purposes as 
the invention extends beyond these limited embodiments. For example, the present invention is 
described in connection with designing a digital system and prohibiting unauthorized use in a 
production setting. However, the present invention can be used to limit and/or prohibit many 
types of unauthorized use of an owner's IP. Consequently, the present invention is not limited 
solely to the prototype testing/production situation. Moreover, the present invention is described 
herein in connection with a PLD. Again, however, the present invention may be incorporated 
into and used with other hardware and with other devices. Moreover, other methods and 
techniques could be used to permit more thorough development and use of digital systems and 
devices by designers while protecting the proprietary interests of the owners of the intellectual 
property incorporated in such systems and devices. 

The present invention allows the owner of intellectual property to distribute IP such as 
programming object files or "POF files" (or authorization codes to create such files) suitable for 
limiting the end customer's use of the owner's IP (for example, allowing only hardware 
prototype testing). The end customer cannot use this POF file in an unlimited or otherwise 
unauthorized manner (using the same example, in a production setting). Consequently, the 
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proprietary interests of the IP owner are better protected because a party being given only limited 
authority to use the owner's IP (again, for example, in testing a hardware prototype or in 
connection with limited production or commercial uses) will not be able to engage in the 
unauthorized use of the IP owner's intellectual property. In the various embodiments disclosed, 
the owner can limit the time during which the licensee can use the IP and/or the mode or manner 
in which the IP is used. 

Generally, embodiments of the present invention employ various processes involving 
data stored in or transferred through one or more computer systems. Embodiments of the present 
invention also relate to a hardware device or other apparatus for performing these operations. 
This apparatus may be specially constructed for the required purposes, or it may be a general- 
purpose computer selectively activated or reconfigured by a computer program and/or data 
structure stored in the computer. The processes presented herein are not inherently related to any 
particular computer or other apparatus. In particular, various general-purpose machines may be 
used with programs written in accordance with the teachings herein, or it may be more 
convenient to construct a more specialized apparatus to perform the required method steps. A 
particular structure for a variety of these machines will be apparent to those of ordinary skill in 
the art based on the description given below. 

In addition, embodiments of the present invention relate to computer readable media or 
computer program products that include program instructions and/or data (including data 
structures) for performing various computer-implemented operations. Examples of computer- 
readable media include, but are not limited to, magnetic media such as hard disks, floppy disks, 
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and magnetic tape; optical media such as CD-ROM disks; magneto-optical media; 
semiconductor memory devices, and hardware devices that are specially configured to store and 
perform program instructions, such as read-only memory devices (ROM) and random access 
memory (RAM). The data and program instructions of this invention may also be embodied on a 
carrier wave or other transport medium. Examples of program instructions include both machine 
code, such as produced by a compiler, and files containing higher level code that may be 
executed by the computer using an interpreter. 

Figure 4 illustrates a typical computer system that, when appropriately configured or 
designed, can serve as an image analysis apparatus of this invention. The computer system 400 
includes any number of processors 402 (also referred to as central processing units, or CPUs) that 
are coupled to storage devices including primary storage 406 (typically a random access 
memory, or RAM), primary storage 404 (typically a read only memory, or ROM). CPU 402 
may be of various types including microcontrollers and microprocessors such as programmable 
devices (e.g., CPLDs and FPGAs) and unprogrammable devices such as gate array ASICs or 
general purpose microprocessors. As is well known in the art, primary storage 404 acts to 
transfer data and instructions uni-directionally to the CPU and primary storage 406 is used 
typically to transfer data and instructions in a bi-directional manner. Both of these primary 
storage devices may include any suitable computer-readable media such as those described 
above. A mass storage device 408 is also coupled bi-directionally to CPU 402 and provides 
additional data storage capacity and may include any of the computer-readable media described 
above. Mass storage device 408 may be used to store programs, data and the like and is typically 
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a secondary storage medium such as a hard disk. It will be appreciated that the information 
retained within the mass storage device 408, may, in appropriate cases, be incorporated in 
standard fashion as part of primary storage 406 as virtual memory. A specific mass storage 
device such as a CD-ROM 414 may also pass data uni-directionally to the CPU. 
5 CPU 402 also is coupled to an interface 410 that connects to one or more input/output 

devices such as such as video monitors, track balls, mice, keyboards, microphones, touch- 
sensitive displays, transducer card readers, magnetic or paper tape readers, tablets, styluses, voice 
or handwriting recognizers, or other well-known input devices such as, of course, other 
computers. Finally, CPU 402 optionally may be coupled to an external device such as a database 

10 or a computer or telecommunications network using an external connection as shown generally 
at 412. With such a connection, it is contemplated that the CPU might receive information from 
the network, or might output information to the network in the course of performing the method 
steps described herein. 

In one embodiment, a system such as computer system 400 used by a customer is in 

1 5 communication with a similar computer system managed by the IP owner. Information and 
programs, including POF files and other files can be provided via an interface 412 for 
downloading by the customer. Alternatively, such information, programs and files can be 
provided to a customer on a storage device. Once in a customer's possession, a memory device 
such as primary storage 406 or mass storage 408 buffers or stores, at least temporarily, a POF file 

20 or other data. The files and other data obtained by the customer from the IP owner can then be 
used in connection with a hardware device, such as a programmable logic device. The details of 
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how IP owners and customers use such inventions are discussed in more detail below. 

As mentioned above, the present invention can be used in a variety of ways to limit a 
licensee's use of the owner's IP. For purposes of this discussion, one embodiment of the present 
invention will be described in the context of limiting a licensee's use of an owner's IP during the 
design of a digital system. While this embodiment provides a good example of how the present 
invention can be used, the example is in no way limiting at all with respect to the scope of the 
invention. 

A design cycle (using, for example, Altera' s OpenCore technology) incorporating one 
embodiment of the present invention is shown in Fig. 2 A. A designer creates an initial block 
diagram 210 and subsequently identifies any megafunctions available for use in the anticipated 
system 220. The designer then can identify and evaluate one or more specific megafunctions 230 
in terms of functionality and the range of parameterization available. After finding the 
appropriate megafunction(s), the designer then can install the megafunction(s) 240 and simulate 
performance 250 within the anticipated circuitry and system using a software simulation. Using 
the present invention in such applications, the designer can fully validate and complete the 
system's design, as called for in step 260, while allowing the IP owner to protect the owner's 
proprietary interests in the licensed IP. A hardware prototype platform typically is and can be 
run for a longer period of time than is practical for software simulation, thus allowing a more 
thorough testing of the newly designed system. Once this prototype validation is completed, the 
IP used can be incorporated into specific devices 270 and be put into production use. 

There are a variety of protective approaches available within the context of the present 
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invention. One embodiment of the invention limits the temporal operation of the IP in a 
hardware prototype setting, making relatively extended periods of use of the intellectual 
property, needed for production use of the IP, impossible. Another approach limits the physical 
and/or electrical operation of the intellectual property, thus prohibiting use of the intellectual 
5 property in a production setting. 

In one embodiment of the invention, the IP owner creates and distributes software which 
disables a prototype hardware platform after a prescribed clock count. By disabling the hardware 
platform within a limited time period, the IP owner reduces or eliminates the risk of a party using 
software and IP intended for prototype testing in a production setting. An embodiment utilizing 

10 a time limited prototype testing version and an unlimited production version of the IP is shown in 
Fig. 2B. At 261, a customer has a design that incorporates IP protectable by one embodiment of 
the present invention. When the customer contacts the owner's compiler at 262 (for example, 
Altera' s Quartus or MAX+PLUSII), a determination is made at 263 as to whether the designer 
has obtained an appropriate IP license from the owner at 264. If not, then the customer is 

15 provided at 265 with a version of the IP containing a hidden counter. If the customer has a valid 
IP license from the owner, then at 266 the designer is provided with a version of the IP without 
the hidden counter. It should be noted that the owner might offer more than only two versions of 
the IP (or offer more types of licenses, depending on the range of potential uses for customers), 
making certain versions available only to appropriate licensees, thereby controlling more 

20 carefully the use of the owner's IP in prototype testing and production uses as well. 

If the IP contains the counter, then the POF file generated at 267 is for prototype testing 
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only (that is, in this embodiment, time limited in its use). If the IP has no counter, then the POF 
file generated at 268 is unlimited and the IP may be used accordingly. Finally, at 269, the 
designer downloads the appropriate POF file into the PLD for implementation with whatever 
hardware is in use. 

Fig. 2C illustrates one example of a counter usable in the embodiment of the present 
invention shown in Fig. 2A and Fig. 2B. The party testing its system sets up a new PLD 
configuration and boots up the system at step 21 1, using a prototype testing POF file provided by 
the IP owner or generated by the customer using an authorization code provided by the IP owner 
(for example, as provided at step 267 in Fig. 2B). At the beginning of the testing procedure, at 
step 212, the IP owner's software initializes its protection counter C=0. The software then 
performs the next step of the testing of the hardware prototype at step 213. At each clock 
measured step of the testing, the software checks to see if the clock counter C has reached the 
time limit T (step 214) set by the IP owner for disabling the hardware platform. If the counter C 
has not yet reached T, then the counter C is incremented at step 215, C=C+1 , and the software 
continues testing. 

If the protection counter C has reached the prescribed limit T at step 214, then the system 
is disabled (for example, by going into its protected idle state) at step 216. The party testing its 
hardware platform can then decide at step 217 whether to reset the counter for more testing. If 
more testing is desired, then the testing party must return to step 21 1 and set up a new PLD 
configuration and/or re-boot the system, which begins the time limited operation of the IP 
owner's software again. 
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This approach is based on the IP owner's knowledge and use of the clock system value of 
the end customer. This information is obtained from the testing party when the testing party 
requests the IP from the owner for testing on the hardware platform. The IP owner will add a 
protection counter clocked to his IP using this known clock frequency, and will use the terminal 
5 count T of the protection counter to disable the IP and force the IP to go into a protected idle 

state where the IP stops working. This protected idle state could be a reset of one or more (or all) 
registers, a global tri-state of the 10, or even a random failure or a combination of failures. The 
IP owner controls the mode(s) of failure. Based on the known clock frequency and the length of 
the protection counter, the IP owner controls the minimum time before IP failure, after which the 

] 0 IP switches to its protected idle state. 

For PCI applications, the typical system clock is 33 MHz or 66 MHz; for Tl/El 
applications it is 8 kHz. By way of example, for 33 MHz PCI applications, and to force the IP 
into its protected idle state after one hour, a 47 bit protection counter C must reach a terminal 
count T of 30*10 9 *60*60=1.08el4. The IP owner can conceal a logic module (for example, a 

15 counter) in the IP for use in a hardware prototype. This logic module inserted by the IP owner 
sets a temporal hardware limitation which makes the IP provided for hardware prototype use 
unsuitable for production uses. In this embodiment, when the 47 bit counter reaches the value 
1.08el4, the PCI IP goes into its protected idle state. This are about 47 logic elements, 
approximately 0.3% of the area of a typical PLD (for example, the APEX400 made by Altera 

20 Corp.). The PCI IP in the hardware PLD prototype board will stop working after one hour of 
operational run time (as counted by the hardware platform, not necessarily the total elapsed 
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time). 

In one embodiment, the only way to exit the protected idle state is to re-configure the 
PLD or re-boot the entire system. This may be acceptable for prototype testing, but might not be 
acceptable in production in the system, which could need to stay configured longer than the one 
hour time limit allowed by the IP owner. 

Because the disabling subroutine of the IP software can be made small compared to the 
rest of the prototype testing POF file, it is impractical for the testing party to attempt to remove 
protection counter C from the POF file. Moreover, it is similarly impractical for the customer to 
try to locate the logic and/or memory cells used for the protection counter in the hardware 
platform to avoid the disabling of the hardware. As a result, the end customer cannot use the 
POF file in production because the typical production system will not support the required 
periodic re-configuration or system re-booting. To use the IP in a production setting, the end 
customer will need to purchase a production POF file (or an authorization code allowing the 
customer to generate a suitable production POF file) which does not force the system to be 
repeatedly re-configured. 

Because the IP owner will be able to limit prototype hardware testing using software, a 
customer will be able to download IP from a web site, simulate it, compile it, and generate a 
prototype testing POF file with the IP, which contains the protection counter. A separate license 
from the IP owner will be required to generate a production POF file that contains the IP without 
the protection counter. 

In lieu of (or in addition to) a temporal limitation on the use of a prototype testing POF 
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file, an IP owner also can impose physical, electrical and/or other modal or operational limits on 
the prototype testing software to permit sufficient hardware prototype testing. While such modal 
and/or operational limits will allow a customer to thoroughly test the hardware platform to 
complete the design process, these limits will prevent use of the IP and software in a production 
5 setting. 

There are a wide variety of parameters that are susceptible to limitation consistent with 
the present invention. While this disclosure will discuss several specific techniques in this 
regard, the present invention is not limited to these particular methods and techniques. Various 
hardware devices and types of software will provide different opportunities for suitable 
1 0 limitation. 

First, the IP owner can limit the number or type of input and/or output signals used by the 
software. For example, if a given device or application requires 20 input signals to function in a 
production setting, the IP owner may limit the prototype testing of the hardware platform to 1 8 
input signals, providing software capable of thoroughly testing the prototype, but being incapable 

1 5 of operating in a production setting. If a customer attempts to add the needed signals (that is, if 
the hardware detects the additional, needed signals), the hardware will then fail in a suitable 
manner (for example, a reset of one or more registers, a global tri-state of the hardware IO, or a 
random failure of some type). 

Analogously, the IP owner can limit the output signals generated by the hardware 

20 platform. For the same reasons, limiting the output signals may provide a thorough testing 

environment, but make production use of the IP and hardware platform impossible. Limitation 
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of outgoing signals from the hardware platform may also include preventing monitoring what the 
IP is doing or its status. Such monitoring may not be necessary for hardware prototype testing, 
but typically is essential in production uses. 

The data format used in the prototype hardware platform also can be limited in a way that 
5 allows a customer to test the hardware platform without making production feasible. For 

example, according to the J.71 1 standard, data compression algorithms differ between the United 
States and Europe. In one embodiment, using the differences established by such a standard, a 
data compression standard limitation can be imposed for prototype testing. In the United States, 
the compression standard for communications data is "u.-low" based. In Europe, the 

10 compression standard for communications data is "a-low" based. By limiting the prototype 

testing to only one standard for testing of an international communications system, an IP owner 
can make testing practical, while use in the intended hardware system would be impossible. 

As can be seen from the foregoing examples, there are numerous ways to limit the 
prototype testing of the hardware platform. While one or more embodiments of the present 

15 invention currently involve imposing limits via the software used on a prototype hardware 

platform, it may also be possible to impose operational limits within the hardware device itself. 
For example, a prototype mask, well known to those skilled in the art, might be usable for 
creating a PLD or other device, making the device circuitry impractical for production uses in 
one or more applications, but making testing of prototypes feasible. The device needed for 

20 production use could then be created using a production mask work. In actual practice the 

difference between the prototype mask and production mask might be nothing more than a single 
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layer in the mask array that alters the device's circuitry in a minimal and practically 
unchangeable manner. Similarly, a device such as a PLD fabricated for prototype testing might 
be augmented by the addition or deletion of a feature as simple as a fuse. Such augmentation 
could be implemented using laser programming. 
5 As can be seen from the foregoing discussion, there are numerous ways to create a 

prototype testing configuration for a system that has passed the simulation phase of development 
and design. Such prototype configurations, whether achieved through augmentation of software 
or hardware, will prevent the unauthorized use of IP outside limits imposed by the owner of that 
intellectual property. Such safeguards will help ensure the protection of IP owners' proprietary 

1Q rights in this technology. 

The present invention also can be used to control production use of the owner's IP as 
well. A design cycle incorporating another embodiment of the present invention is shown in Fig. 
3. A designer creates an initial block diagram 310 and subsequently identifies any 
megafunctions available for use in the anticipated system 320. The designer then can identify 

1 5 and evaluate one or more specific megafunctions 330 in terms of functionality and the range of 
parameterization available. After finding the appropriate megafunction(s), the designer then can 
install the megafunction(s) 340 and simulate performance 350 within the anticipated circuitry 
and system. The designer can complete the system's design, as called for in step 360 (including, 
perhaps, using one embodiment of the present in the testing process). Once the prototype 

20 validation is completed, the IP used can be incorporated into specific devices 370 and be put into 
production use. This production use, however, also can be controlled in the same way testing is 
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controlled. The POF file downloaded by the designer may limit or otherwise control operation 
of the hardware through techniques similar to those discussed in connection with the controlled 
testing of hardware. 

The many features and advantages of the present invention are apparent from the written 
description, and thus, the appended claims are intended to cover all such features and advantages 
of the invention. Further, since numerous modifications and changes will readily occur to those 
skilled in the art, the present invention is not limited to the exact construction and operation as 
illustrated and described. Hence, all suitable modifications and equivalents are deemed to fall 
within the scope of the invention. 
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